Перейти к основному содержимому

7.05. Коммуникация и интеграция

В РАЗРАБОТКЕНЕ ДЛЯ НОВИЧКОВНЕ ОБЯЗАТЕЛЬНО
Разработчику Архитектору Инженеру

Коммуникация и интеграция​

Коммуникация микросервисов — это процесс взаимодействия между независимыми сервисами, которые составляют распределённую систему. В отличие от монолита, где все компоненты находятся в одном процессе, микросервисы должны взаимодействовать через сеть.

Интеграция микросервисов — это процесс объединения независимых сервисов в единую систему, чтобы они могли эффективно взаимодействовать и решать общие задачи.

Интеграция выполняется по следующим подходам:

  1. Прямые вызовы (Point-to-Point), когда каждый сервис напрямую вызывает API других сервисов.
  2. Шина интеграции (Integration Bus), когда центральная шина (ESB, Enterprise Service Bus) управляет взаимодействием между сервисами.
  3. Событийно-ориентированная интеграция, когда сервисы взаимодействуют через публикацию и подписку на события (Apache Kafka).

Интеграционная шина (Enterprise Service Bus, ESB) — это архитектурный подход, при котором используется центральный компонент для управления взаимодействием между сервисами. ESB предоставляет стандартные механизмы для маршрутизации, преобразования данных и координации сервисов.

Она выполняет функции перенаправления запросов между сервисами, преобразования форматов данных (XML → JSON), логирование всех взаимодействий и управление доступом. Но, как можно заметить, эта шина и становится единой точкой отказа - если сервисы умирают, вся структура ещё работает, но если упадёт шина - всё остановится, и шина является узким местом при высоких нагрузках.

ESB характерна для SOA-архитектуры (Service-Oriented Architecture):

image-5.png

Event-Driven Architecture (EDA) определяет, что сервисы публикуют события, а другие сервисы подписываются на них.

Сервис публикует событие, например, «заказ создан», и это событие отправляется в шину событий (Event Bus), которая выступает центральным каналом для передачи событий. Шина событий получает событие и рассылает его всем заинтересованным сервисам. Разные сервисы подписываются на события и реагируют на них. К примеру, сервис оплаты создаёт счёт для оплаты, сервис уведомлений формирует и отправляет уведомление клиенту, а сервис логистики планирует доставку.

image-6.png

Интеграционные взаимодействия — это способы обмена данными и координации между различными системами, приложениями или сервисами. В зависимости от характера взаимодействия их можно разделить на три основных типа: синхронные , асинхронные и реактивные.

Контракт в контексте интеграций — это формальное соглашение между взаимодействующими системами, которое определяет:

  • Формат данных (структура, типы полей, кодировка).
  • Правила обмена данными (протокол, методы передачи, синхронизация).
  • Обязательные и необязательные значения (поля, которые должны или могут быть заполнены).

Контракты обеспечивают согласованность между системами и предотвращают ошибки при обмене данными.

Обязательные значения — это поля, которые всегда должны присутствовать в сообщении. Например, если система ожидает user_id для идентификации пользователя, то это поле должно быть обязательным.

Необязательные значения могут отсутствовать, и система должна корректно обрабатывать их отсутствие. Например, поле description может быть необязательным.

Payload — это фактические данные, передаваемые между системами. В зависимости от типа данных payload может быть нескольких видов:

  1. Малые данные - простые структуры (например, JSON-объекты или строк). К примеру, сообщение об успехе операции вроде «success».
  2. Двоичные данные - файлы, изображения, видео или другие бинарные форматы. Передаются через протоколы, поддерживающие двоичные данные (например, HTTP с multipart/form-data или WebSocket).
  3. Большие данные - сложные структуры данных, большие массивы или файлы. Например, CSV-файл с миллионами записей.
  4. Форматы сериализации:
    • JSON;
    • Protobuf (Protocol Buffers);
    • XML.

Обязательность обеспечивает, что все необходимые данные передаются корректно. Если поле order_id обязательно, то система должна вернуть ошибку, если оно отсутствует.

Сертификация предполагает использование сертификации для обеспечения безопасности и совместимости. К примеру, HTTPS использует SSL/TLS-сертификаты для шифрования данных.

Процесс проверки данных на соответствие называется валидацией. Валидация может быть строгой, когда все данные проверяются на соответствие контракту, а в случае несоответствия - запрос отклоняется; и нестрогой, когда система игнорирует дополнительные поля или незначительные нарушения контракта.